Frequently Asked Questions
Other FAQs -Enterprise Edition FAQ
andLicensing FAQ
Expand/collapse all
How does the utility know that an update
has been made to a file in the server folder?
My users are getting the error message "The version of this file is not
compatible with the version of Windows you're running. Check your computer's
system information to see whether you need an x86 (32-bit) or x64 (64 bit)
version of the program, and then contact the software publisher." or
"This app can't run on your PC. To find a version for youir PC, check
with the software publisher."
Short answer: delete startmdb.exe as it is now a 1K or 2K shortcut file. Import
startmdb.exe from the downloaded zip file. Right click on the exe, properties
and in the attributes section check it as read only.
Long answer. Very occasionally a user will encounter a strange message which
comes from their Windows OS and tey choose what appears to be the sane option.
Windows then replaces the exe on the server share with a shortcut pointing to
itself. You can verify this by renaming startmdb.exe to startmdb.lnk and you
will see it's properties as a shortcut.
I'm suddenly no longer seeing all the options: (New, Update, Validate, Run, Lockout, etc). It still
works, but it only has “Run Config File.”
I moved the Auto FE Updater folder from another system and ....
You are now seeing the same screen the users would see if they clicked on the exe file directly. Your work station name and
network user id are stored in the AutoFEUpdater.ini configuration settings file. This file can be found in the same
folder as the startmdb.exe and contains Master1, 2, and 3 entries. Only workstations and user ids present in those
entries are allowed access to all the options.
1) The best solution is to open the AutoFEUpdater.ini configuration settings file with Notepad and replace the workstation name with
your current workstation name. This will preserve other settings in the file such as your license key number.
2) The quickest solution is to delete the AutoFEUpdater.ini file and click on the StartMDB.exe so it will recreate
the file with your current workstation name in it. However you will lose a number of other settings in that file.
What about Windows 10?
The Auto FE Updater utility works just fine under Windows 10.
I'm trying to install the Auto FE updater, but I get the following message when I try to extract:
File skipped unknown compression method?
Have you tried downloading the Windows Compressed Folder file on the download page?
I'd like to copy files in subfolders down to the users target folder.
You can now use the uncompress files
option for this. A better solution will be coming but it will be a while yet.
Why didn't the uncompress files unzip the contents of the zip file when I was testing?
I'm getting error messages when the user downloads a Zip file such as CRC calculation failed, CRC error, Error in decompressed size or Error writing file but when I ask the user to find the Zip file it's not there.
My users are getting the following message: "1184 - It appears you are already running this application. Please exit and try starting the application again. A Microsoft Access Record Locking Information (LDB/LACCDB) file was found and could not be deleted. " What is happening?
The utility is now checking the target folder to see if an LDB/LACCDB
file is present. The problem is that bizarre things can happen if a user is
already in the FE database file and if the Auto FE Updater utility needs to
copy down the new FE database file over top the old one. However some
folks are telling me that this is a problem. I've added a check box on the
Seldom Used Update form which states
"Ignore the 1184 - Already Running App message"
I want to use the RemoteApp feature of Terminal Server.
My users are getting the message "The Auto FE Updater is no longer free for use. Please purchase a license as your trial period is over." "You can contact your support personnel who can immediately set a seven day trial period extension. You can continue to use this utility." But I'm not seeing this message. How can I immediately set the seven day trial period extension?
Go to the File, Tools & Help menu and choose Tools. Then select Request Trail Period Extension.
If someone is in the database BE; if I "lockout" while people are in - will that cause corruption in my access file; or will it simply let them finish what they are busy with and only lock out new attempts to access?
Lockout only sets a flag in the config file. It does not do anything
to the Access files. So yes you can set it and the users already in have
an unlimited amount of time to finish. Any users that try to go into the
app will, of course, be unable to do so.
Note that the Enterprise Edition has a
Lockout - Create Email to Users feature which allows you to
send an email to those users currently in the BE. Once you go to unlock the
database you can send an email to those who were in the database as well as those
who attempted to use the app while it was locked out.
When I open the
View
users in backend
database files
form I'm only
seeing my name
in the list
while the other
users have a
line stating
"Problem
encountered
reading data
from log
database".
You are possibly testing the Auto FE Updater and have two different versions on your server with two different AutoFEUpdater Log.MDB files. When you are running the newer version the utility is pulling in all the workstation ids from the Access or SQL Server database file but the Auto FE Updater Log.MDB only has your userid in it. You can see this yourself by opening the AutoFEUpdater MDB file in Access and open the SystemUsers table. The solution is to open the Enterprise Edition form and change the Auto FE Updater Log.MDB file to point to the active AutoFEUpdater Log.MDB file with all the users in it.
I
can't see any
connections in
the
View
users in backend
database files
screen but I
know there are
lots of users in
the SQL Server
database.
The DBA or IT administrators must give you explicit permissions to view this data by issuing the following SQL Server command.
GRANT VIEW SERVER STATE TO
I
can't see all
the users on a
Citrix/Terminal Server
in the
View
users in backend
database files
in the Access
backend.
The Access LDB/LACCDB only records the workstation name. The only way to determine the name of the user is to query the log database file for the last user of that workstation. This, of course, doesn't work for Terminal Server users. You need to implement the AutoFEUpdater_ExitApp code as found in the Auto FE Updater Sample Code Vx.xx.mdb in the distribution zip file.
I don't understand how to implement the Auto FE Updater in a Citrix/Terminal Server environment.
The users are pinning the Access FE database file to the task bar thus bypassing the Auto FE Updater version checking. This is in Windows 7 and Windows 2008 Server R2.
Do I have to use the Create User Email Setup command button every time I make a new version of the Access Front End file available to the users?
No, this is a one time action for each user and is only required for users who are new to your application or through some problem have had the shortcuts removed from their system. Once they've clicked on the shortcut in the email the first time the utility will create a desktop, quick launch or programs shortcut. From now on they only click on the shortcut(s) you've configured the Auto FE Updater to create.
I inserted some blank lines in the User Setup Email HTML body and they didn't appear in the email.
You're looking at the raw HTML code so you need to insert the html paragraph code </p>.
Access is crashing whenever I use your utility but when I click on the FE it works fine.
Ensure
your command
line parameters
have spaces in
between the
arguments.
For example:
CommandLine=
/runtime/wrkgrp
" \\Server\Shared...."
is a problem.
My corporate email
client isn't supported by the Auto FE Updater.
My users are getting the Access 2007 Security Warning - Certain content in this database has been disabled? Is there anything that can be done.
A: In the
Auto FE Updater
program
Update the
configuration
file and select Trusted
Locations
screen.
Then
click the check
box appropriate
to your version
of Access.
I'm getting a
"
Open File -
Security
Warning: The
publisher could
not be
verified. Are
you sure you
want to run this
software?
"
message.
Where does the shortcut, .LNK file, reside? The configuration file(s)? And startmdb.exe?
These files should reside in a directory on the server, likely called Auto FE Updater. They should be be in the same directory as the Auto FE Updater utility but that's not a requirement. While you can have other files in the Auto FE Updater folder I wouldn't recommend it.
Where do the FE file reside on the server that will be copied down to the workstations?
The FE Access database file()s (MDB, MDE, ACCDB, ACCDE, ACCDR, ADP or ADE) must reside in it's own folder on the server. Along with any other files you want to copy down to the client in the same folder such as add-in MDEs or the Leban's PDF DLLs.
I'm a bit confused about the directory structure required.
You require a directory on the server which is exclusively for the use of the Access front end (FE) database file which is to be copied to the client directory whenever it's updated. As well as any other files required such as MDE add-ins or DLL files. All files in this directory will be copied to the client workstation. This is the MDB/MDE/ACCDB/etc which you update on your own system and then copy up to the server when you complete a feature or bug fix.
The shortcut (which has a .LNK extension although you never see that), Auto FE Updater configuration files and startmdb.exe as well as the backend can be placed in any other directory you desire. This directory can contain any other files you want. However I'd suggest you dedicate a directory to the Auto FE Updater and it's associated files.
Can the Auto FE Updater also be used on a front end.mdb (instead of mde)?
Yes, the Auto FE Updater can be used with any files. ADPs, ADEs, Word or Excel files, VB or C++ .exes, etc. All that matters is if a file(s) is placed in the FE directory on the server with a different date, or a new file, then it gets copied down automatically the next time the user runs the shortcut.
One person uses the utility to distribute an Excel Add-In to a few other users in his company. But as he seldom does any updates to it he chose to not create any shortcuts. He also uses the Create User Setup Email to let the other users know when there is an update
On the server that I use the variable called %username% instead. Is that version related or a choice of the administrator?
I get the user name using an API call. I chose to use variable names surrounded by %s in the INI that were the same as the command prompt variables just for some consistency.
It's not creating shortcuts.
- or -
I'm getting the message "1030 - Shortcut creation was not successful for unknown reasons.:
1) Can you create shortcuts on your or the users desktop manually by right clicking? Some IT departments restrict this capability.
2) You can now create shortcuts in the users My Documents folder. Not the best option but if the IT department has restricted this what choice do you have?
Where do I indicate the location of my security file?
You need to specify the location of the workgroup file in the Command Line entry just as you would when creating a shortcut.
For example /wrkgrp \\server\share\workgroup.mdw
If you are using the Start Method=Autoselect you will also want to use the MDWFile option as well so the Auto FE Updater knows which version of Access to use to open the client FE MDB/MDE. You can avoid this by using a different Start Method other than Low Macro Security.
I'm getting the message "Jet 3033 - You do not have the necessary permissions to the MDB/MDE. This is likely due to the MDB/MDE being secured. You must then specify the MDW file path and name, User and Password in the INI file. "
Is there any way to insert a command into the Auto FE Updater .ini file to tell it to run either a batch file or .exe file before it does anything else?
Yes, although you can only start a .bat, .cmd or exe file. You can't then start an MDB/MDE running using the Auto FE Updater. The bat, cmd or exe file will then have to start the MDB/MDE/etc You can use the Executable Start Method option.
The following error message is appearing:
1019 - The following error occurred while attempting to determine the Access/Jet version of the file [path to our front end] (while using DAO Version 3.6)
Jet 3033 - You do not have the necessary permissions to the MDB/MDE. This is likely due to the MDB/MDE being secured. You must then specify the MDW file path and name, User and Password in the INI file.
- or -
Jet 3033 - You do not have the necessary permissions to the MDB/MDE. This is likely due to the MDB/MDE being secured. You must then specify the Workgroup File settings in the configuration file."
The only time
the Auto FE
Updater should
be giving you
the 1019 error
is if you are
using the
Start Method of
Auto Select
which I don't
suggest anyone
uses unless they
have a very good
reason. Try
using the File
Extension option
instead.
If you do want
to use ULS and
Start Method of
Auto Select you
will also need
to set the
parameters at
the
Workgroup File
settings page.
I'm trying to use an ACCDR file and I'm getting the following message:
Microsoft Access cannot open this file.
This file was converted to runtime mode by changing its file extension to .accdr. This file will open only when Access is in runtime mode.
To open the file, either double-click it in Windows Explorer, open it by using a shortcut or use the /runtime command-line switch.
To modify the design of this database, rename it with an .accdb file name extension, and then open it in Access.
Go to the
Command Line
screen and
add /runtime to
the Command
Line. In a
future version I
will do that
automatically if
an ACCDR file is
found.
I would like the application to use an alternate .mdw file when starting. I've placed the /wrkgrp command switch in the CommandLine section, but for some reason it's not picking the command line up at all.
Recent updates to the logic should have fixed this unless you are using the Start Method=Low Macro Security. For Low Macro Security only due to how Windows works I have no way of passing a command line to Access.
Why are there two shortcuts being created on the users desktop?
You've specified both the Desktop Shortcut and the Common Desktop Shortcut. Remove the Common Desktop Shortcut option as it no longer works in Windows Vista and newer. Microsoft have restricted updates to the common folders to be by administrators only.
The workstations are frequently used by multiple users. I don't want other users' to be able to see this application or have it be accidentally deleted when the workstation is imaged.
The FE should be installed in the users Application Data directory on the workstation. In the Target screen use the %appdata% environment variable.
I have to do some preprocessing in VBScript and then have different FEs on different servers called depending on where the computer is located in the WAN.
Create a configuration file with the appropriate settings for each of the servers along with StartMDB.exe. Once you've determined the local server then call StartMDB.exe using command line parameters such as "\\server1\share1\StartMDB\StartMDB.exe" /cmd /inifile"\\server1\share1\Auto FE Updater\.ini"
I'd like to add comment lines to the AutoFEUpdater.INI file to annotate which computer name belongs to whom.
1) The only work station names in the AutoFEUpdater.INI file should be those of the developers as these entries give those workstation users the AutoFEUpdater GUI to work with the INI files
2) You can't do it on the individual lines Master1-3 as INI files don't work that way without extra logic on my part. However you can add additional lines in the INI file as you wish. These will be ignored by the Auto FE Updat
Is there any way to insert a command into the Auto FE Updater .ini file to tell it to run either a batch file or .exe file before it does anything else?
Yes, although you can only start a .bat, .cmd or exe file. You can't then start an MDB/MDE running using the Auto FE Updater. The bat, cmd or exe file will then have to start the MDB/MDE/etc You can use the Executable Start Method option.
Yes, although you can only start a .bat, .cmd or exe file. You can't then start an MDB/MDE running using the Auto FE Updater. The bat, cmd or exe file will then have to start the MDB/MDE/etc You can use the Executable Start Method option.
I'm moving the files from one server to another server. How do I easily use the Auto FE Updater to get the users to use the FE from a folder on the new server?
- and -
Q: I want to move the BE MDB to a different folder on the same server.
There are two parts to this. One is to replace the FE MDE so it's linked to the new server folder and folder structure and the other to change the target of the shortcut to use the new Auto FE Updater INI file.
On the day of the switchover delete/rename the BE MDB file from the old server so just in case something gets missed they can't work with the old MDB file. You're moving it to a new server anyhow so don't leave it easily available on the old server.
Copy the new FE MDE which is linked to the new BE server and folder to the FE path on the old server. This way when the users run the old shortcut for the first time they will get switched over to the new FE MDE.
Update the AutoFEUpdater INI file on the old server to be the same as the INI file on the new server. When the users run the new INI for the first time they will get a warning message saying the shortcut on their system is different. Use the Shortcut Error Message Handling option set to "Correct problem with no message to user" on the configuration file on the old server to ignore that message so the shortcut gets updated transparently to the user.
Use the New INI Path And File entry in the old INI file. This line is only used when moving servers or such as this will rewrite the path and name of the StartMDB exe and INI file in the target of the shortcut.
This can all be tested ahead of time.
Why does using the Auto FE Updater strip the menu bar from the Access program the users see? And what about the right click menus while in forms?
That's caused by the runtime switch present in the Command Line entry in the sample INI files published with versions prior to 2.0. Remove that line from the INI file. If you are distributing a runtime you must create your own menu bar. Distributing the file in this fashion is slightly more secure thus I've chosen this as being the default in the past.
Alternatives to the Auto FE Updater
|